Bi-directional digital game port driver

ABSTRACT

The invention uses the conventional PC game port as a port for a digital game input device, employing a Digital Game Port (DGP) protocol which uses the four discrete or button lines and a single analog line (one of four) on the conventional game board to form a dual serial port. Data from a DGP control device is packetized with each packet consisting of 13 bytes of data. The packets or blocks are then grouped into frames. A frame consists of two blocks of data. A total of two frames are transmitted to the driver for each driver request. The 13-byte data block is divided between six one byte analog values and four bytes of digital data, with three bytes that identify and define the device. This device definition and identification is unique. By sending the device identification and configuration to the driver, the driver can determine not only the presence of the device but also very specific aspects of the device. The hardware configuration of the cable enables the driver to uniquely identify the first unit connected to the host computer as the master unit. The driver identifies the other units, if any, as slave units. Up to 3 additional slave units may be chained from the master digital game port input device by such cables.

[0001] A portion of the disclosure of this patent document containsmaterial that is subject to copyright protection. The copyright ownerhas no objection to the facsimile reproduction by anyone of the patentdocument or the patent disclosure, as it appears in the Patent andTrademark Office patent file or records, but otherwise reserves allcopyright rights whatsoever.

BACKGROUND OF THE INVENTION

[0002] 1. Field of the Invention

[0003] This invention relates generally to controllers for games andsimulator programs implemented on a personal computer (“PC”) and, moreparticularly, to bi-directional controller drivers having the capabilityof receiving transmitted digital controller data to the PC game portresponsive to a PC microprocessor instruction.

[0004] 2. Description of the Related Art

[0005] The PC has been through a good deal of change and evolution sinceits initial introduction. However, in some areas, the PC has changedlittle. One such area is the way in which the PC interfaces to externaldevices. Countless add-in cards and interfaces have been developed but,with few exceptions, these new add-in cards and interfaces have notbecome standard to the basic PC. The standard peripheral interfacestypically found on all new PCs are the parallel interface (printerinterface), serial interface(s), the game board interface, the keyboardport, and sound card interface. Bi-directional communication between thehost PC and external devices has generally been restricted to the serialinterface(s). The parallel interface is notably not truly abi-directional interface. The keyboard port has also been adopted forbi-directional communications (See U.S. Pat. Nos. 5,396,267 and5,610,631; see also U.S. Pat. No. 4,824,111 to Hoye, et al.) but doesnot provide a truly bi-directional interface.

[0006] One problem with the current system is that the primarybi-directional interface, the serial interface, has speed limitationsand is typically dedicated to other external devices such as theprinters. When not dedicated to the system printer, the serial interfaceis in constant use by modems, faxes, scanners, mouse, and the like.Therefore, the serial interface has not been readily available tosupport game controllers.

[0007] Conventionally, a PC is enabled to be controlled by externalmanual control devices by means of a game board or card, which providesan external game port into which control devices, such as joysticks,rudders, hand-held game controllers and the like, can be plugged.Widespread compatibility is essential to the ability to mass market awide variety of games and simulation programs.

[0008] Industry standards have been developed for game cards forpersonal computers such as those commonly referred to asIBM-compatibles. The universal adoption of these standards means thatany external manual input device designed to control such computers andsoftware must be compatible with the industry-standard game port. Anyinput device lacking such compatibility will not be able to be used tointerface with conventional personal computers through standard gameboards and will not be widely accepted.

[0009] One problem is that the industry standard game port provides onlya limited number of inputs: four discrete signal inputs for receivingdiscrete signals signifying “On” and Off” and four analog signal inputsfor receiving variable voltage signals, such as output by apotentiometer, which are continuously variable over a limited range. Thenumber of game boards that could be plugged into a conventional PC wasalso limited. A multiport game card is disclosed in commonly assignedU.S. Pat. No. 5,245,320 to Bouton. Consequently, the number ofcontrollers supported by a standard game port, and the number ofallowable functions communicated thereby, is severely restricted.

[0010] Additionally, the game card or board has been typically thoughtof as an input only device, that is, not having the capability ofcommunication to and from the external device.

[0011] The industry-standard game port is a very simple, somewhatprimitive, interface, especially in how it handles the analog inputs.The game port appears to the host PC, more particularly to the PCmicroprocessor, as an Input/Output (“I/O”) address. The microprocessorcommunicates with I/O interfaces, like the game port, by sendinginstructions to the address assigned to the particular I/O device. Asingle I/O interface may have two or more ports, each port will have anindividual address assigned.

[0012] The first game port will usually be assigned an address 0201 hex(base 16) or 513 decimal. To access the game card to read a button, forinstance, the microprocessor performs an I/O READ from address 201 h.The result is an 8-bit value where each of the 4 buttons is assigned asingle bit. When a button is pressed on the game controller, a contactclosure to ground is applied on the game port at a pin on the connectorthat corresponds to the button input to the game port. A logic lowvoltage at the input pin and at the corresponding bit indicates that thebutton has been pressed.

[0013] The byte read from the game port is typically configured asfollows: BIT 7 6 5 4 3 2 1 0 But4 But3 But2 But1 Y2 X2 Y1 X1 Where: But4indicates button 4; But3 indicates button 3; But2 indicates button 2;But1 indicates button 1; X1 indicates first X analog position; Y1indicates first Y analog position; X2 indicates second X analogposition; and Y2 indicates second Y analog position.

[0014] For example, if the 8 bit value read from the game port is 1 1 10 0 0 0 0, the button pressed was button 1. You may notice that theanalog positional values X1, Y1, X2, and Y2 are also represented by asingle bit in this example. This is not the value of the analog inputbut rather a flag.

[0015] Reading an analog positional value is not as simple as reading abutton value. U.S. Pat. No. 5,245,320 to Bouton, incorporated herein byreference, describes and illustrates the conventional game controllercoupled to the game port. The analog positional values must be read byfirst causing the microprocessor to write to the address 201 h byissuing a WRITE, 201h instruction. This instruction causes a monostablemultivibrator or one-shot to fire an output voltage pulse which chargesup to power supply voltage VCC. The width of the resulting pulse will beproportional to the resistance of the external device connected to thegame port. The resistance of the external device will, in turn, beproportional to the position of the controller in one axis, the X axis,for example. This is because the output of the one-shot is presented toa capacitive load located on the game port and a resistive load locatedon the controller. Game controllers, for instance a joystick, have apotentiometer in both the X and Y axis. The resistive value of both ofthese potentiometers reflects the position of the joystick in therespective axis. The one-shot drives the analog line high and the timethat the line stays high is a function of the time it takes for thecapacitive value of the game port to charge through the deviceresistance. The RC-time constant, comprising the capacitive load of thegame port and the resistive load of the joystick or controller, definesthe width of the pulse. The PC microprocessor must then turn this pulsewidth value into a value that reflects the device position capable ofuse in games and other programs. Typically, this conversion isaccomplished by using a counter timer. When the microprocessor writes toaddress 201 h, a timer coupled to the one-shot is started. The timer isstopped when the output voltage pulse from the one-shot finally goeslow. The timer ending count is proportional to the RC-time constant, andtherefore indicative of the value of resistance and controller position.

[0016] A drawback is that the characteristics of the analog inputs canvary significantly from machine to machine. Game developers haveattempted to circumvent this problem by providing calibration functionsthat normalize the game port inputs. These calibration functions willread the analog inputs for the extremes of travel of the respectiveexternal controller and, interactively with the user, assign values tothese points. These assigned values are then used by the driver runningon the host PC to scale and offset the raw analog input values read fromthe external controller. Additionally, since there are four analoginputs to be read, the microprocessor must divide its time between thefour inputs. During the polling of the four inputs, the microprocessortypically masks service interrupts from other systems within the PC inorder to eliminate deviation in position accuracy.

[0017] Attempting to address these and other limitations of theconventional game board, game developers have used the four discretesignal inputs and the four analog inputs in a variety of creative ways.One such way is described in U.S. Pat. No. 5,389,950 to Bouton, one ofthe present inventors, incorporated herein by reference. This patentdescribes a video game controller for inputting command signals to agame port having a finite number of discrete and analog signal inputsand providing a plurality of additional discrete outputs multiplexed onone of the analog outputs. The controller has a plurality of switcheseach coupled to the one analog output via a different value resistance.Circuitry in the game board in combination with programming in thecomputer game or simulation software recognizes discrete voltage levelsinput from the controller via the one analog port as different discretecommands. This enables the range of commands that can be input from avideo game controller to be substantially increased without making anychange to the base computer software. A similar method is described inU.S. Pat. No. 5,459,487 to the aforementioned inventor, incorporatedherein by reference.

[0018] U.S. Pat. No. 5,593,350 to Bouton, et al., incorporated herein byreference, describes a high precision game card that generates a digitalsignal corresponding to each analog input signal from a controller. Eachdigital signal has a digital value proportional to the number of “reads”(READ instructions) to the game card by the PC microprocessor. Thedigital signals can therefore be read by the computer without disablingthe computer interrupts. The game card converts the analog input signalsto a corresponding numeric value and this value is compared with anoutput of a counter which counts the number of “reads” by the computer.If the number of “reads” equals or exceeds the numeric representation,the corresponding digital signal is deasserted. The digital signals areinitially asserted responsive to a “write” (WRITE instruction) to thegame card by the computer microprocessor. Alternatively, the numericrepresentations can be provided directly to the computer over thecomputer data bus. This embodiment provides all of the numericrepresentations over a single address.

[0019] Yet another example of novel ways in which the conventional gameboard interface has been used is disclosed in U.S. Pat. No. 5,245,320again to the aforementioned inventor, incorporated herein by reference.In this invention, the game port provides support for at least twomulti-functional game controllers via a single PC I/O bus connector. Anaddress decoder selectively enables one of the game controllers in orderto access the control input received therefrom. A program operating inthe personal computer polls separate addresses within the gamecontroller address space to receive input information from the differentcontrollers. Jumper blocks map each of the plurality of controllers toseparate and distinct addresses, in order to avoid address conflicts andprovide flexibility.

[0020] U.S. Pat. No. 5,551,701 to Bouton, et al., incorporate herein byreference, describes yet another example of a video game system. Thecomputer game control system in a PC with a game port and keyboard portincludes a joystick. The joystick is connectable to both the game portand the keyboard port of the PC. The throttle and joystick controllerinputs are reconfigurable to work with different video game programs bydownloading a new set of keycodes from the personal computer via thekeyboard port to a microcontroller and non-volatile memory in thethrottle controller. The throttle and joystick controller have variableinputs which can be input to the PC in either analog or digital form.The digital inputs can be calibrated by changing their correspondingkeycodes.

[0021] These are and other developments have been implemented by thepresent inventors in several commercially available products, includingthe F-16 FLCS™ Flight Control System game controller (“FCS”). The FCScontroller includes analog circuitry mounted on a printed circuitassembly that completes the charging circuit found on the game board.The timer and charging circuit found on the game port is activated bythe PC microprocessor by a WRITE, 201 h instruction, as explained above.Once a charging cycle has begun, other circuitry on the board detects apredetermined charge level on this analog circuitry. The FCS responds tothe detection of a predetermined charge level by processing data andtransmitting the processed data back to the PC microprocessor via thekeyboard port.

[0022] Other examples of novel embodiments of the game port interfaceexist, including those disclosed in U.S. Pat. No. 5,396,267 to Boutonand U.S. Pat. No. 5,610,631 to Bouton, et al., both incorporated hereinby reference. Unfortunately, the aforementioned attempts to expand gameport functionality have failed to fully address the limitations inherentin the conventional game board.

[0023] As games and simulations become more complex and sophisticated,game operators not only desire more game controller functions but moreflexibility to configure controller functions to fit their individualplaying style. Especially, there is a need for many more configurablediscrete or binary control inputs. The existing discrete or binary inputcapabilities of a conventional game port, even augmented by a keyboardport input device, does not permit the implementation of such a widerange of control inputs.

[0024] Existing game controllers have not provided much improvement orsimplification in the configuration of the game input devices orexpansion of the number of external devices supported. Moreover, theprimitive manner in which the analog inputs are handled by the game portleads to variations in controller characteristics from machine tomachine, as mentioned above. A related drawback is that a significantamount of microprocessor or driver time is spent in determining theposition of the controller.

[0025] The advent of the Universal Serial Bus (“USB”) might one daybypass these problems by increasing the number of bi-directional serialI/O ports on a PC, but that capability is not readily available as yet.Moreover, USB cannot readily be implemented on tens of millions of PCsnow in use which rely on a game port as the primary interface ofjoysticks and other game controllers to PCs.

[0026] Accordingly, a need remains for a bi-directional game/simulationsystem including a game controller that allows inputting a plurality ofexternal user-actuable control signals to a driver and subsequently to avideo game or simulation program running on a PC via a conventional PCgame port responsive to PC microprocessor commands.

SUMMARY OF THE INVENTION

[0027] It is, therefore, an object of the invention to provide abi-directional game/simulation system that overcomes the problemsassociated with prior art game/simulation systems.

[0028] Another object of the invention is to provide a game controllerthat communicates with a driver running on a PC using a standard PC gameport.

[0029] Yet a further object of the invention is to provide a systemincluding a driver that allows communication between a PC having asingle game port and more than a single game controller.

[0030] Yet a further object of the invention is to provide a driver thatautomatically identifies the game controller.

[0031] The invention is a new method of using the existing game portinterface, one that not only eliminates the inherent inconsistencies ofthe existing game port but also significantly expands the number ofdevices that can be connected to a single game port. There are severalaspects of the invention and the manner in which it can be implementedthat are both creative and unique. The invention uses the conventionalPC game port in an entirely new way, as a port for a digital game port(DGP) input device or controller arranged and operating according to theinvention, and in so doing uses the game port as a dual bit streamserial port.

[0032] As mentioned above, it is clear that the value of such analoginputs can change from machine to machine and from game card to gamecard depending upon speeds, components, etc. One way the inventioneliminates this variation is to convert the analog position value of thedevice at the device and then to transmit the value in digital form to areceiving driver for further processing at the PC. This eliminates thedependence upon the variant elements of the PC and interface between thePC and the device. Commonly-assigned U.S. Pat. No. 5,593,350 to Bouton,discloses an analog-to-digital game card capable of converting analoginputs from a controller to digital representations and inputting themto the PC data bus responsive to a WRITE instruction from the PCmicroprocessor to the game card. The present invention enables digitalinput from the DGP controller through a conventional game card.

[0033] The controller employs a Digital Game Port protocol according tothe invention, which uses the four button lines and a single analog line(one of four) on the convention game board to form a dual serial port.The data transmitted in this dual serial configuration is packetizedwith each packet consisting of 13 bytes of data. The packets or blocksare then grouped into frames. A frame consists of two blocks of data. Atotal of two frames are transmitted to the host for each host request.

[0034] The 13 byte data block is divided between six one byte analogvalues and four bytes of digital data. In addition each packet containsthree bytes that identify and define the device. This device definitionand identification is quite unique and one of the special features ofthe Digital Game Port protocol. Since the device identification andconfiguration can be sent to the driver, the driver can determine notonly the presence of the device but also very specific aspects of thedevice when using the Digital Game Port protocol.

[0035] The hardware configuration of the Digital Game Port cable is suchthat the first unit connected to the host computer is uniquelyidentified as the master unit by the driver. Other units in the chainare identified as slave units. Up to 3 additional slave units may bechained from the master digital game port input device by way of aspecial digital game port input cables. Each digital game port devicecan support the same number of analog and digital inputs as the masterunit and each is uniquely identified. In the full configuration theDigital Game Port protocol will support 6 analog and 4 digital (32buttons) times 4 units, giving at total of 24 analog and 128 digital orbutton inputs. This is a significant expansion of the existing game portinput capability.

[0036] The foregoing and other objects, features, and advantages of theinvention will become more readily apparent from the following detaileddescription of a preferred embodiment of the invention which proceedswith reference to the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

[0037]FIG. 1 is a block diagram of the interconnection of four devicesin a Digital Game Port system of the present invention;

[0038]FIG. 2 is a block diagram of an alternative interconnection offour devices in a Digital Game Port system of the present invention;

[0039]FIG. 3A is a functional block diagram of a Digital Game Portsystem of the present invention;

[0040]FIG. 3B is a schematic diagram of the Digital Game Port system ofFIG. 3A;

[0041]FIG. 4 are waveform timing diagrams of a four-Digital Game Portdevice system as shown in FIGS. 1 and 2;

[0042]FIG. 5 is a timing diagram of the contents of a Digital Game Portdata packet in the diagram of FIG. 4;

[0043]FIG. 6 is a timing diagram of the contents of a Digital Game Portdata byte in the diagram of FIG. 4;

[0044]FIG. 7 is a block diagram of the software architecture of theDigital Game Port system of the present invention; and

[0045] FIGS. 8A-8B are flowcharts of the driver software of the presentinvention.

[0046] TABLE 1 is an example of a 15-pin DSUB connector pin assignmentfor the Digital Game Port system shown in FIGS. 3A and 3B.

[0047] Appendix A is a printout of assembly language code for apreferred implementation of the controller firmware using the MicrochipPIC 16C 711-04 microcontroller of FIG. 3B.

[0048] Appendix B is a printout of the code for a currently preferredimplementation of the driver code.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT OF THE INVENTION

[0049] The Digital Game Port (“DGP”) protocol uses the four button linesand a single analog line (one of four) on the conventional game board toform a dual serial port. The data transmitted in this dual serialconfiguration is packetized with each packet consisting of 13 bytes ofdata. The packets or blocks are then grouped into frames. A frameconsists of two blocks of data. A total of two frames are transmitted tothe host for each host request.

[0050] The 13 byte data block is divided between six one byte analogvalues and four bytes of digital data. In addition each packet containsthree bytes that identify and define the device. This device definitionand identification is quite unique and one of the special features ofthe DGP protocol. Since the device identification and configuration canbe sent to the host, the host can determine not only the presence of thedevice but also very specific aspects of the device when using the DGPprotocol. By doing so, the user is spared having to manually enterdevice specifications into the host PC through the computer keyboard,for example, for use by the host software.

[0051]FIG. 1 is a block diagram of the interconnection of four-DGPdevices of the present invention. As shown in FIG. 1, the fullconfiguration DGP system 10 includes four DGP devices coupled to astandard PC game port 12. DGP system 10 includes DGP devices 13, 17, 18,and 19 that are connected to each other by means of standard 15-pin DSUBconnectors commonly used in game port interfaces. Typically, a DGPdevice has two external connectors 15 and 16. The hardware configurationof the DGP protocol cable is such that the first unit connected to thehost computer is uniquely identified as master DGP device 13. Otherunits are identified as slave DGP units 17, 18, and 19. The second unitconnected to the host computer is identified as first slave 17, thethird unit connected to the host computer is second slave 18, and thefourth unit is third slave 19. As shown in FIG. 1, up to 3 additionalslave devices 17, 18, and 19 may be chained from master device 13 by wayof special game port input cables. Each DGP device can support the samenumber of analog and digital inputs as master device 13 and each isuniquely identified according to their position in the chain. In thefull configuration, the DGP protocol will support 6 analog and 4 digital(32 buttons) times 4 units, resulting in a total of 24 analog and 128digital or button inputs. This is a significant expansion of theexisting game port input capability.

[0052]FIG. 2 is an alternate block diagram of the interconnection offour-DGP devices in DGP system 10 that shows a terminal DGP device 20.The difference between slave devices 17, 18, and 19 and terminal device20 is that terminal device 20 has a single external connector 21 insteadof two external connectors 15 and 16 present in slave devices 17, 18,and 19.

[0053]FIG. 3A is a functional block diagram illustrating selectedelements of the system of the present invention. For the sake ofbrevity, not all the systems components are shown in FIG. 3A. However,the elements omitted are well known in the art and need not be describedherein in farther detail. Computer system 22 includes a microprocessor27, memory 25 that may include read-only memory (“ROM”), as well as,random access memory (“RAM”). Computer system 22 also includes display23 and its associated interfaces, keyboard 24, and game port 26. Gameport 26 includes a charging circuit comprising timer 26, resistor R1,and capacitor C1 coupled to one of the analog terminals of game port 26.The various components of the computer are coupled together by a busthat includes both data lines, control lines, and the like. A power bus(not shown) distributes power to the various components.

[0054] DGP device 28 includes a buffer 31, a microcontroller 29, and anon-DGP device port 30. As is shown in FIGS. 1 and 2, four DGP deviceslike DGP device 28 can be chained together via slave port 33 andexternal connector 16 (shown in FIGS. 1 and 2). Microcontroller 29 is aconventional component utilizing memory, including ROM and RAM, as wellas other conventional microprocessor elements such as I/O ports whoseoperation need not be described in detail herein. DGP device 28 alsoincludes an analog circuit comprising R2 and C2 coupled to an analogterminal of the game port for completing the game board chargingcircuit. An example of an R2 value is 20KΩ and of C2 is about 1000 pF.

[0055]FIG. 3B is a schematic diagram of the present invention. In thepresently preferred embodiment, microcontroller 29 is implemented by aMicrochip PIC16C711 and buffer 31 in a Motorola hi-speed CMOS HCT244Tri-state buffer with TTL compatible inputs. (The use of parts havingTTL compatible is important to the design. Furthermore, the use of twodriver gates for the clock and two for the data is also important. Thisprovides enough drive current for the protocol to work with all knowngame cards. The interface circuitry is also intended to allow the DGPdevice to be “hot-pluggable.” For traditional game port devices it isrecommended to power off the computer before connection. DGP devices donot have this restriction.) The schematic shown in FIG. 3B includes asingle DGP device but, as is mentioned above, three additional DGP slavedevices can be chained together via the slave port. The DGP protocol isimplemented in the DGP device by microcontroller 29 as shown in FIGS. 3Aand 3B. Microcontroller 29 samples any digital (button, switch, etc.)inputs local to the DGP device and converts these inputs into thedigital game port input stream. In addition, the DGP device can alsoinclude a port 30 for connection to a non-DGP device. Port 30 allows anon-DGP device 32 to be interfaced with a game board through the DGPdevice so as to convert non-DGP device data to the DGP data stream. Bydoing so, a non-DGP device can be used as if it were a DGP device.

[0056] Table 1, included with the attached drawings, is an example of aDGP protocol pin assignment for a 15-pin DSUB connector. DC1 refers tomaster device 13 that controls the timing synchronization of slavedevices 17, 18, and 19. Any DGP peripheral is capable of being a masterDGP device. The master or slave device determination is made based onthe position the device has in the chain; the first device in the chain,connected directly to the PC, is always the master. A fully compliantgame port having 4 discrete or button inputs and 4 analog axes inputswill support a maximum of four DGP devices (one master and three slavedevices) connected in any one chain.

[0057] The operation of DGP system 10 will be described with referenceto FIG. 4 that illustrates waveform timing diagrams of a four DGP devicesystem. Each DGP device will communicate to the host computer in thesame manner. The master-slave relationship is simply one of timing.Master device 13 and first slave unit 17, if present, transmit data tothe host during the first frame. Master device 13 transmits data using apair of discrete or button input lines while slave device 17, ifpresent, transmits data using another pair of discrete or button lines.

[0058] The sequence of events to acquire data from a DGP device is muchdifferent than reading either button or analog data in the conventionalgame port configuration.

[0059] The driver will initiate a write to I/O address 201 the same aswith a normal game port read; however, from this point on, allsimilarity ends. The game port write causes the analog one shot to fireresulting in a low to high transition of the Data Request In line.Waveform A in FIG. 4 illustrates the Data Request In line. A typical lowstate of this line is a 2.2KΩ pull-down resistor to ground and a typicalhigh state is a Hi-Z input of 2 VDC minimum. In the presently preferredembodiment, the DGP device detects the Data Request In signal transitionin less than 126 μs assuming a worst case capacitor value on the PC gameport of 10000 pF±20%.

[0060] Instead of using the Data Request In signal transition to timethe charge of a capacitor, the rising edge is detected by the DGP deviceas an interrupt or data request. DGP master device 13 will respond tothis data request by processing data and by echoing the request to anyattached slave units 17, 18, or 19. (The reason that the Master echoesthe “data request” to Slave1, and Slave1 echoes to Slave 2, and Slave2to Slave3, is so that interrupt response time is not affected by all 4DGP loading the same data request line. In other words the response timeremains the same regardless of how many units are connected.) At thispoint, master device 13 starts to transmit a data frame to the host.

[0061] The data requests generated from the Master to the Slave1,generated from Slave1 to Slave2, and generated from Slave2 to Slave3 areinterrupts used as “early warning signals” to each of the slaves thatthe synchronization signal (Frame Sync) is about to occur. Each of theslaves in turn transmit their data packets in response to theappropriate edge of the synchronization signal. Slave1 transmits itsdata to the PC in response to the rising edge of a synchronizationsignal from the master. Slave2 (and Slave3) transmits its data to the PCin response to the falling edge of a synchronization signal from themaster.

[0062] The software in APPENDIX A is the same for a DPG controller usedas a slave as when it is used as the Master. A slave device isdifferentiated by detecting a slave frame sense signal (low) on pinJ2-15 in FIG. 3B. Responsive to detecting the low signal, the slaveaccesses code in the APPENDIX A for the slave mode, which causes theslave, responsive to a data request signal, to look for the Frame Syncsignal to be low. When that signal goes low, the slave beginstransmitting its frame of data.

[0063] Waveforms B-E illustrate the echoing of Slave Data requestsignals from master device 13 to slave units 17, 18, and 19. A DGPdevice in slave mode responds to the Data Request In signal transitionby pulsing its Data Request Out and subsequently being ready for anappropriate change in the Frame Sync signal. Master DGP device 13changes the state of the Frame Sync signal from low to high beginningthe transmission of Frame 1.

[0064] During Frame 1, master device 13 and first slave 17 first changethe state of the Data line from a Hi-Z state to a logic low state andthen transmit synchronized data using the two pairs of available buttonlines. After the Frame 1 data transfer is complete, the master device 13changes the state of the Frame Sync signal from high to low beginningthe transmission of Frame 2. Second slave 18 and third slave 19 respondto this high to low transition of the Frame Sync signal by firstchanging the state of the Data line from a Hi-Z to a logic low state andthen transmit synchronized data to the host using the two pairs ofavailable button lines as shown in Waveforms G-J of FIG. 4. After thetransmission of a Frame of data both the Data and Clk lines return to aHi-Z state.

[0065] In the presently preferred embodiment, the transmission time of aFrame of data takes no less than 1255 μs. The current implementationuses a 12 μs clock only +/−0.5%. The design allows for a maximum of 9 μslatency between the state change of Frame Sync and the actualtransmission of data. The data itself takes 1560 μs typically after thelatency. Furthermore, the Master unit waits an additional 16 μstypically before changing the state of Frame Sync again. This avoids apotential contention problem caused by variation in microcontrollercrystal frequency from one DGP unit to another. It is important to notethat 12 μs was selected because, even though interrupts are off in thePC, Direct Memory Access (DMA) is still occurring, particularly forsound effects. Since a relatively large amount of data is beingtransmitted, it is likely that DMA will “steal” some bus cycles andtherefore create data errors by missing bits. By using 12 μs, the bittime is sufficiently long that data errors do not occur, because cyclestealing is not long enough to lose any bits.

[0066] A data packet from master device 13 is placed on one button lineand a clock signal on another button line to synchronize the data asshown in Waveforms G-J. The data signal provides data start and stoppulses to assure proper data framing. The clock is used by the PC todetermine when the data on button line paired with the clock line isvalid. (It is somewhat of a misnomer to call the clock signal a clock;it is more correctly a bit-wise data valid pulse. Any time the clock islow, the data is guaranteed to be valid, even on the transition edges ofthe clock. This is significant in that it eliminates the need forover-sampling like a UART does. We can sample at exactly 12 μs withoutthe loss of information. It helps defeat the Nyquist criteria.) Thus,simultaneously with the transmission of clock and master device data onone button pair, slave device data, if a slave device is present in thechain, can be transmitted on another button pair.

[0067] After the driver software initiates the write to input/outputaddress 201, it continuously reads 201 for a fixed time and loads amemory buffer block with the data for post-processing. The host softwaredetects the initial start pulse to assure synchronization and thendetermines when data is valid by detecting a high to low transition ofthe button line. When valid, the host software samples and saves thedata. After reading both frames, the host has all the necessary data forup to 4 chained DGP devices. This data is then passed to the hostsoftware program/game for use as needed.

[0068]FIG. 5 is a timing diagram showing an example of the content ofthe data packet transmitted during a single frame. A frame consists of13 bytes of data. In this example, data is transmitted in the followingorder: analog byte 1, analog byte 2, digital byte 1, analog byte 3,analog byte 4, digital byte 2, analog byte 5, analog byte 6, digitalbyte 3, digital byte 4, ID byte, FW byte, and Definition byte. The IDbyte is an identifier string that uniquely identifies the DGP device tothe host and, more particularly, the host software. The FW byteidentifies the firmware revision of DGP internal microcontroller 29. Themost significant nibble of the definition byte is a binaryrepresentation of the number of analog bytes with real data provided bythe DGP device. The least significant nibble is the number of realdigital bytes provided by the DGP device. The reason for the ordering ofthe data bytes, and the existence of the definition byte, is so the PCsoftware only has to hang around long enough to get the data it needs.For instance, if a DGP device only has two axes and 8 switches, the PCresident software can return data to the game sooner.

[0069]FIG. 6 is a timing diagram showing an example of the contents of adata byte. Each data byte has 10 bits consisting of a start bit, a stopbit, and 8 data bits arranged from least significant (“LSB”) to mostsignificant bit (“MSB”) as shown. A DGP device first transmits a startbit in a logic low, spacing, or high voltage state. Next, 8 data bitsare sent LSB to MSB. Finally, a stop bit is transmitted in a logic high,marking, or low voltage state. The DGP protocol supports 6 analog and 4digital (32 buttons) times 4 units, giving at total of 24 analog and 128digital or button inputs. This is a significant expansion of theexisting game port input capability.

[0070]FIG. 7 is a block diagram of the software architecture of the DGPsystem shown in FIGS. 1-2. The software architecture includes a game orsimulation program 70, the operating system 72, the driver 76, and thecontroller firmware 78 running on the DGP device 13. The game orsimulation program 70 runs on the PC. When the game or simulationprogram 70 needs positional or other information from the DGP device 13,the game or simulation program 70 makes a standard call to the operatingsystem 72. The operating system 72 is preferably Windows 95®manufactured by Microsoft® Corporation or a Windows 95® compatibleoperating system. The operating system 72 includes a conventionalroutine 74 that handles the collection of controller data like theVJOYD.VXD routine in Windows 95®. For devices that are not directlysupported by Windows 95® such as DGP device 13, the VJOYD.VXD routine 74calls the DGP-specific driver 76 to collect the data. The interfacebetween the VJOYD.VXD routine 74 and the driver 76 is defined by theWindows 95® operating system and is outside the scope of the presentinvention. The driver 76 handles all communication between the DGPdevice 13, the operating system 72, and the game or simulation program70. Although a single DGP device 13 is shown in FIGS. 7 and 8, a personskilled in the art should understand that driver 76 can supportcommunication between a chain of up to four DGP devices, the operatingsystem 72, and the game or simulation program 70.

[0071] The operation of the driver 76 will be explained in more detailwith reference to the flowchart shown in FIGS. 8A and 8B. At step 80,the operating system 70 initiates reading data from the DGP device 13 byrequesting controller data from the driver 76. The driver 76 issues awrite to I/O address 201 at step 82. The game port write causes theanalog one shot to fire, resulting in a low to high transition of theData Request In line, as explained above. The DGP master device 13detects the rising edge of the Data Request In signal and interprets thedetected edge as an interrupt or data request. The DGP device 13responds to this data request by processing data (step 83) and byechoing the request to any attached slave units 17, 18, or 19 (step 84).At step 86, the DGP device 13 transmits controller data back to thedriver using the digital input terminals of the game port responsive tothe write instruction issued from the driver 76. The DGP device 13transmits the controller data serially using a first digital inputterminal to transmit the controller data signal and a second digitalinput terminal to transmit a first clock signal associated with thecontroller data signal.

[0072] If two or more DGP devices are chained together, the masterdevice 13 will transmit its corresponding data and clock signals on thefirst and second digital input terminals followed by a data and clocksignal associated with a second slave controller 18. The first slavedevice 17 transmits a first slave controller data signal using a thirddigital input terminal and a second clock signal using a fourth digitalinput terminal. If a third slave controller 19 exists in the chain, thethird slave controller 19 transmits its corresponding data and clocksignals after the first slave device 17 transmits its data and clocksignals using the third and fourth digital input terminals.

[0073] After issuing the write instruction, the driver 76 monitors thegame board's digital input terminals (step 88) until a logic high to lowtransition of the first clock signal is detected (step 90). At step 92,the driver 76 reads the controller data signal on the second digitalinput terminal. At step 94, the driver 76 transfers the controller datasignal read at step 92 into a register the driver 76 maintains inmemory. After the driver 76 completes transferring the controller datasignal into memory (step 96), the driver 76 processes the contents ofthe memory register and extracts the actual digital and analog positionvalues as well as the identification information included therein. Atstep 98, the driver 76 decodes the stored controller data signal byidentifying and removing start and stop bits included in each data byteof information. The driver 76 the places the decoded values in a returndata structure defined by Windows 95® (step 100) and passes control backto the VJOYD.VXD routine 74 (step 102). The VJOYD.VXD routine 74 scalesthe decoded values, if necessary, and passes the results back to therequesting application (step 104). Appendix B is a program listing of acurrently preferred implementation of code for driver 76. The bspread.cand bspstate.c routines included in Appendix B together implement theabove-described functions of the driver 76 including polling the I/Oports and reading and decoding data.

[0074] Having described and illustrated the principles of the inventionin a preferred embodiment thereof, it should be apparent that theinvention can be modified in arrangement and detail without departingfrom such principles. We claim all modifications and variations comingwithin the spirit and scope of the following claims. TABLE 1 ConnectorPin Assignments From To Unit Conn Pin Description Unit Conn PinDescription DC1 J1 1 −5 VDC Input Internally wired to J2-1 PC GP 1 +5VDC Output (regulated) in order to provide power out for next DC1 J2 1+5 VDC Output. DC unit in the chain. DC2 J1 1 +5 VDC Input. DC1 J1 2 TXDATA 1 Output. Internally PC GP 2 Button 1 Input. connects to a highcurrent drive DC1 J2 10 TX DATA 1 Input. (>40 mA) CMOS output through anRC DC2 J1 10 TX DATA 2 Output. filter. The RC filter is a 47Ω/1000 pFlow pass. Data is sent during frame 1. Also internally wired to J2-10 inorder to connect to TX DATA 2 from next DC unit in the chain. Thissecond set of data is sent during frame 2. Outputs are Hi-Z when nottransmitting. See Section 4.1 Game Port Button Line Capacitive LoadingAnalysis for a more detailed discussion. DC1 J1 3 DATA REQUEST IN. Hi-ZTTL PC GP 3 X1 Analog Input. Input. Pullup = 20 kΩ with 1000 pF cap toground. Connects to an HCT244 input. V_(INHIGH)(min) = 2.0 VDC. Outputused as a rising edge interrupt to indicates the PC has sent a datarequest. 20 kΩ pullup guarantees Vin low max of 0.542 V. Using worstcase game card values yields a rise time variance of 14 to 126 μs. SeeSection 4.2 Data Request Delay Analysis for a more detailed discussion.DC1 J1 4 GND Input. Internally wired to J2-4 in PC GP 4 GND Output.order to provide ground reference for DC1 J2 4 GND Output. next DC unitin chain. Also used to set DC1 J2 9 Master/Slave Sense Output. theMaster/Slave Sense Output to the DC2 J1 4 GND input. next DC unit in thechain. DC2 J1 9 Master/Slave Sense Input. DC1 J1 5 GND Input. Internallywired to J2-5 in PC GP 5 GND Output. order to provide ground referencefor DC1 J2 5 GND Output. next DC unit in chain. DC2 J1 5 GND Input. DC1J1 6 No Connection. PC GP 6 Y1 Analog Input. DC1 J1 7 TX CLK 1 Output.Identical circuit to PC GP 7 Button 2 Input. TX DATA 1 Output. Alsointernally DC1 J2 14 TX CLK 1 Input. wired to J2-14 in order to connectto DC2 J1 14 TX CLK 2 Output. TX CLK 2 from next DC unit in the chain.This second set of data is sent during frame 2. Outputs are Hi-Z whennot transmitting. DC1 J1 8 +5 VDC Input. Internally wired to J2-8 PC GP8 +5 VDC Output (regulated). in order to provide power out for next DC1J2 8 +5 VDC Output. DC unit in the chain. DC2 J1 8 +5 VDC Input. DC1 J19 MASTER/SLAVE SENSE Input. PC GP 9 +5 VDC Output (regulated) Internallyconnected to Hi-Z TTL DC1 J2 15 SLAVE FRAME SENSE OUT. input through 220Ω isolation resistor DC2 J1 15 SLAVE FRAME SENSE IN. with a 4.7 kΩpullup. If logic 1 (Vin = +5 V) unit is a master unit. Internally wiredto J2-15 to provide SLAVE FRAME SENSE OUT to next DC unit in the chain.Only a unit directly connected to the master will receive a SLAVE FRAMESENSE IN of +5 V. 220 Ω provides impedance match. DC1 J1 10 TX DATA 2Output. Connected to no PC GP 10 Button 3 Input. internal components.Internally wired DC1 J2 2 TX DATA 2 Input. to J2-2 TX DATA 2 Input/ Thiswire DC2 J1 2 TX DATA 1 Output. reroutes TX DATA 1 Output from the nextDC unit in the chain to TX DATA 2 Output of this unit TX DATA istherefore alternated. DC1 and DC3 TX DATA ends up connected to Button 1line of the PC. They send their data during alternating frames. DC2 andDC4 TX DATA connects to Button 3 line of the PC. They send their dataduring alternating frames. DC1 J1 11 No Connection. PC GP 11 X2 AnalogInput. DC1 J1 12 SLAVE FRAME SYNC IN. Internally PC GP 12 GNDOutput/MIDI Output. connects to CMOS output through a 2.2 kΩ isolationresistor in master mode (Hi-Z input in slave mode). Logically this inputis a “don't care” to the master unit Master unit must drive against thiseffective pull-down as the other side of the resistor is connected toMASTER FRAME SYNC OUT. μC is capable of providing the required 2.4 mA ofdrive current. Impedance matched to input of other DC units. Outputidles at low for low current. Drive hi into 2.2 kΩ load only duringframe 1 transmission. See Section 4.3 MIDI Compatibility. DC1 J1 13 NoConnection. PC GP 13 Y2 Analog Input. DC1 J1 14 TX CLK 2 Output.Connected to no PC GP 14 Button 4 Input. internal components. Internallywired DC1 J2 7 TX CLK 2 Input. to J2-7 TX CLK 2 Input/ This wire DC2 J17 TX CLK 1 Output. reroutes TX CLK 1 Output from the next DC unit in thechain to TX CLK 2 Output of this unit. TX CLK is therefore alternated.DC1 and DC3 TX CLK ends up connected to Button 2 line of the PC. Theysend their clocks during alternating frames. DC2 and DC4 TX CLK connectsto Button 4 line of the PC. They send their clocks during alternatingframes. DC1 J1 15 SLAVE FRAME SENSE IN. PC GP 15 +5 VDC Output Or MIDIInternally connected to Hi-Z TTL Input. input through 220 Ω isolationresistor. If logic 1(Vin = +5 V) DC slave unit transmits data and clockduring frame 1. This signal input is a logical “don't care” to a masterunit. See Section 4.3 MIDI Compatibility. DC1 J2 1 +5 VDC Output. SeeJ1-1 description. PC GP 1 +5 VDC Output (regulated). DC1 J1 1 +5 VDCInput. DC2 J1 1 +5 VDC Input. DC1 J2 2 TX DATA 2 Input Reroutes TX PC GP10 Button 3 Input. DATA 1 Output from next DC unit in DC1 J1 10 TX DATA2 Output. the chain to J1-10 TX DATA 2 Output. DC2 J1 2 TX DATA 1Output. Connected to no internal components. DC1 J2 3 DATA REQUEST OUTOutput. DC2 J1 3 DATA REQUEST IN Input. CMOS output with 4.7 kΩ pull-up.Any unit either master or slave responds to a DATA REQUEST IN byproviding a logic 1(+5 V) pulse on DATA REQUEST OUT. Each successive DCunit receives it's interrupt from the previous unit and provides aninterrupt to the next unit. This insures a worst case delay of 3 latencyperiods between the first interrupt edge on DATA REQUEST IN to all DCunits ready to transmit. Loading effects on the X1 Analog Input of thePC by multiple DC units is eliminated. Only the “rise time” of DATAREQUEST IN of the Master (based upon the PC's variable capacitance) isan uncertainty. This signal idles low. DC1 J2 4 GND Output. See J1-4description. PC GP 4 GND Output. DC1 J1 4 GND Input. DC2 J1 4 GND Input.DC1 J2 5 GND Output. See J1-5 description. PC GP 5 GND Output. DC1 J1 5GND Input. DC2 J1 5 GND Input. DC1 J2 6 No Connection. DC2 J1 6 NoConnection. DC1 J2 7 TX CLK 2 Input. Reroutes TX CLK 1 PC GP 14 Button 4Input. Output from next DC unit in the chain DC1 J1 14 TX CLK 2 Output.to J1-14 CLK 2 Output. Connected to DC2 J1 7 TX CLK 1 Output. nointernal components. DC1 J2 8 +5 VDC Output. See J1-8 description. PC GP8 +5 VDC Output (regulated). DC1 J1 8 +5 VDC Input. DC2 J1 8 +5 VDCInput. DC1 J2 9 Master/Slave Sense Output. Providing PC GP 4 GND Output.a logic 0 on this line indicates to the DC1 J1 4 GND Input. next DC unitit the chain that it is a DC1 J2 4 GND Output. slave unit. See J1-4description. DC2 J1 4 GND Input. DC2 J1 9 Master/Slave Sense Input DC1J2 10 TX DATA 1 Input. See J1-2 PC GP 2 Button 1 Input. Description. DC1J1 2 TX DATA 1 Output. DC1 J1 10 TX DATA 2 Output. DC1 J2 11 NoConnection. DC2 J1 11 No Connection. DC1 J2 12 MASTER FRAME SYNC Output.DC2 J1 12 SLAVE FRAME SYNC Input. CMOS output. Master unit drivesagainst 2.2 kΩ pulldown. Also drives into 2.2 kΩ series resistor into 50pF of gate capacitance. This yields <1 μs rise time delay between unitsin addition to cable delay. DC1 J2 13 No Connection. DC2 J1 13 NoConnection. DC1 J2 14 TX CLK 1 Input. See J1-7 Description. PC GP 7Button 1 Input. DC1 J1 7 TX CLK 1 Output. DC2 J1 14 TX CLK 2 Output. DC1J2 15 SLAVE FRAME SENSE Output. PC GP 9 +5 VDC Output (regulated).Rerouted MASTER/SLAVE SENSE DC1 J1 9 +5 VDC In put. Input. Only thefirst two DC units in DC2 J1 15 SLAVE FRAME SENSE Inpt. the chain willdetect a logic high (+5 V) here.

[0075]

What is claimed is:
 1. A method for bi-directional communication betweenat least one game controller, a game port mounted on a personalcomputer, and a driver running on the personal computer, the game porthaving a charging circuit responsive to a personal computer instruction,analog input terminals, and digital input terminals, the at least onegame controller having an analog circuit coupled to the game port forcompleting the charging circuit, the method comprising the steps of:sending the personal computer instruction from the driver to the gameport; charging the charging circuit from a first level to a second levelresponsive to the personal computer instruction; detecting apredetermined level on the charging circuit; transmitting controllerdata to the driver using a predetermined number of the digital inputterminals responsive to detecting the predetermined level on thecharging circuit; and processing the transmitted controller data.
 2. Themethod for bi-directional communication of claim 1 wherein transmittingthe controller data to the driver includes serially transmitting thecontroller data to the driver using the predetermined number of digitalinput terminals.
 3. The method for bi-directional communication of claim1 wherein transmitting the controller data to the driver includes:transmitting a controller data signal on a first digital input terminal;and transmitting a clock signal on a second digital input terminal. 4.The method for bi-directional communication of claim 3 whereinprocessing the transmitted controller data includes: continuouslymonitoring the second digital input terminal for a transition of theclock signal; detecting a transition of the clock signal; and readingthe controller data signal responsive to detecting the transition of theclock signal.
 5. The method for bi-directional communication of claim 4including shifting the controller data signal into a block of memoryafter reading the controller data signal.
 6. The method forbi-directional communication of claim 4 wherein the transmittedcontroller data includes a plurality of data bytes, each data bytehaving a corresponding start and stop bit and wherein processing thetransmitted controller data includes: identifying the start and stop bitfor each of the plurality of data bytes; and decoding the each of theplurality of data bytes after identifying the corresponding start andstop bits.
 7. The method for bi-directional communication of claim 6wherein the at least one game controller is a master game controllerwherein decoding each of the plurality of data bytes includesidentifying the master game controller.
 8. The method for bi-directionalcommunication of claim 1 wherein the at least one game controllerincludes a master game controller and at least one slave game controllerand wherein transmitting controller data to the driver includes:transmitting a master controller data signal on a first digital inputterminal; transmitting a first clock signal on a second digital inputterminal, the first clock signal corresponding to the master controllerdata signal; transmitting a slave controller data signal on a thirddigital input terminal; and transmitting a second clock signal on afourth digital input terminal, the second clock signal corresponding tothe slave controller data signal.;
 9. The method for bi-directionalcommunication of claim 8 wherein processing the transmitted controllerdata includes: continuously monitoring the second digital input terminalfor a transition of the first clock signal; continuously monitoring thefourth digital input terminal for a transition of the second clocksignal; detecting a transition of the first clock signal; detecting atransition of the second clock signal; reading the master controllerdata signal responsive to detecting the transition of the first clocksignal; and reading the slave controller data signal responsive todetecting the transition of the second clock signal.
 10. The method forbi-directional communication of claim 9 including shifting the masterand slave controller data signal into a memory block after reading themaster and slave controller data signal.
 11. The method forbi-directional communication of claim 8 wherein the master and slavecontroller data signal includes a corresponding plurality of data bytes,each data byte having a corresponding start and stop bit and whereinprocessing the transmitted controller data includes: identifying a startand a stop bit for each of the plurality of master and slave data bytes;and decoding each of the plurality of master and slave data bytes afteridentifying the corresponding start and stop bits.
 12. The method forbi-directional communication of claim 11 wherein decoding each of theplurality of master and slave data bytes includes identifying the masterand slave controller.
 13. A bi-directional game/simulation system forsimulating operation of a complex system having a plurality ofuser-controlled functions, the system comprising: a personal computerhaving a digital microprocessor operable under the control of a videogame/simulation program, a display for displaying images produced by theprogram, and an input/output bus for connecting peripheral input andoutput devices to the digital microprocessor; a game board coupled tothe input/output bus having a finite number of digital and analog inputterminals and a portion of a charging circuit responsive to a personalcomputer instruction, the charging circuit coupled to one of the analoginput terminals; at least one game controller having an analog circuitcoupled to the analog input terminal for completing the chargingcircuit; detecting means in the at least one game controller fordetecting a predetermined charging level on the charging circuit;processing means in the at least one game controller for processingcontroller data responsive to the detected predetermined charge level;transmitting means coupled to the processing means in the at least onegame controller for transmitting the processed controller data using apredetermined number of the game board digital input terminals; and adriver program running on the personal computer for processing thetransmitted controller data received at the game board digital inputterminals.
 14. A bi-directional game/simulation system according toclaim 13 wherein the transmitting means transmits a game controller datasignal on a first digital input terminal and a first clock signal on asecond digital input terminal.
 15. A bi-directional game/simulationsystem according to claim 14 wherein the driver includes monitoringmeans for monitoring the second digital input terminal for a transitionof the first clock signal.
 16. A bi-directional game/simulation systemaccording to claim 14 wherein the game controller data signal includes afirst finite number of analog position data bytes of the at least onegame controller, a second finite number of digital position data bytesof the at least one game controller, and a third finite number ofidentification data bytes identifying the at least one game controller.17. A bi-directional game/simulation system according to claim 14wherein the driver includes: detecting means for detecting a transitionof the first clock signal; reading means for reading the game controllerdata signal responsive to detecting the transition of the first clocksignal; storing means for storing the read game controller data signalinto a block of memory; and decoding means for decoding the stored gamecontroller data signal.
 18. A bi-directional game/simulation systemaccording to claim 13 wherein the at least one game controller includesa slave and a master controller and wherein the transmitting meanstransmits a master controller data signal on a first digital inputterminal, a first clock signal on a second digital input terminal, aslave controller data signal on a third digital input terminal, and asecond clock signal on a fourth digital input terminal, the first clocksignal corresponding to the master controller and the second clocksignal corresponding to the slave controller.
 19. A bi-directionalgame/simulation system according to claim 18 wherein the mastercontroller data signal includes: a first finite number of analogposition data bytes of the master controller; a second finite number ofdigital position data bytes of the master controller; a third finitenumber of identification data bytes identifying the master controller; afourth finite number of analog position data bytes of the slavecontroller; a fifth finite number of digital position data bytes of theslave controller; and a sixth finite number of identification data bytesidentifying the slave controller.
 20. A bi-directional game/simulationsystem according to claim 18 wherein the driver includes: detectingmeans for detecting a transition of the first and second clock signals;reading means for reading the master controller data signal responsiveto detecting the transition of the first clock signal; reading means forreading the slave controller data signal responsive to detecting thetransition of the second clock signal; storing means for storing theread master controller data signal into a block of memory; storing meansfor storing the read slave controller data signal into a block ofmemory; decoding means for decoding the stored master controller datasignal; and decoding means for decoding the stored slave controller datasignal.